home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 1805 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.1 KB

  1. Path: informatik.tu-muenchen.de!fischerj
  2. From: fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS friendly part II
  5. Date: 23 Jan 1996 17:48:37 GMT
  6. Organization: Technische Universitaet Muenchen, Germany
  7. Distribution: world
  8. Message-ID: <4e371l$92b@sunsystem5.informatik.tu-muenchen.de>
  9. References: <38232020@kone.fipnet.fi> <9PxXx*kka@aargh.incubus.sub.org> <4des65$bgk@serpens.rhein.de> <38232076@kone.fipnet.fi> <4djpni$t6h@serpens.rhein.de> <4dm07g$ouh@sunsystem5.informatik.tu-muenchen.de> <4dmm79$9hu@serpens.rhein.de> <4e0jhq$f0q@sunsystem5.informatik.tu-muenchen.de> <4e114i$4o8@serpens.rhein.de>
  10. NNTP-Posting-Host: hphalle5.informatik.tu-muenchen.de
  11. Originator: fischerj@hphalle5.informatik.tu-muenchen.de
  12.  
  13.  
  14. In article <4e114i$4o8@serpens.rhein.de>, 
  15. mlelstv@serpens.rhein.de (Michael van Elst) writes:
  16. |> fischerj@informatik.tu-muenchen.de (Juergen "Rally" Fischer) writes:
  17. |> 
  18. |> >don't you think someone knowing about OS-coding, but beeing 
  19. |> >a friendly, non-agressive fellow, couldn't achieve more ? ;)
  20. |> 
  21. |> Ignoring the discussion as always.....
  22.  
  23. what am I ignoring ? I just can't ignore your sad 'c0d3r' talk.
  24.  
  25. |> 
  26. |> No, I am quite sure that noone can achieve anything if the other
  27. |> side is as stubborn as you.
  28.  
  29. naaah. I try to get OSsy solutions, but if I loose too much vs
  30. a "vanilla A1200 hack", then I at least will provide the hack
  31. as option. What is bad about this.
  32.  
  33. |> >? how to optimize move.l (a0)+,(a1)+ ;) 
  34. |> 
  35. |> By starting the DMA channel ?
  36. |> By using movem.l to send bursts of data ?
  37. |> By funneling the data into a FIFO at a constant address ?
  38. |> 
  39. |> You do not know. The driver does.
  40.  
  41. yes, in can optimize that way, but this could still be less ideal
  42. than direct render to vram.
  43.  
  44. |> 
  45. |> >I'd suggest the driver gives you a buffer you can render to,
  46. |> 
  47. |> And again you are limited to a single possible architecture.
  48.  
  49. ??? the driver can give you fastmem, chipmem, vram, swapspace,
  50. whatever depending to architecture...
  51.  
  52. |> 
  53. |> >If the card can display multiple buffers and writing bytewise to it
  54. |> >is faster than writing bytewise to fastmem + copying the buffer,
  55. |> >the driver will give you an adress in vram. voila :)
  56. |> 
  57. |> But why should writing bytewise be faster ?
  58.  
  59. texture mapping loops write bytewise to fastmem. If vram is as fast,
  60. you can render into it and save the time of copying.
  61.  
  62. |> 
  63. |> >So making the OS more sucking
  64. |> 
  65. |> Again just insults.
  66. I explained what I mean. 
  67.  
  68. |> 
  69. |> >would keep then from using 
  70. |> >OS-functions to get fast animation ? 
  71. |> 
  72. |> Fast animation doesn't need user-level access the graphics buffer.
  73.  
  74. On architectures where vram is quite quick and fastmem is quite slowe and
  75. copying is done with cpu it does need that. This time you are the one that
  76. doesn't take care of all possible architectures!
  77.  
  78. |> 
  79. |> >any games showing fast gfx naturally want to have a screen (better
  80. |> >say screenbuffer) they can render to. also OS-coded ones will still
  81. |> >want "a complete screen allocated to you." because no game is fun
  82. |> >on half screens.
  83. |> 
  84. |> This surely depends on the screen, especially on the screen _size_.
  85.  
  86. you are talking about a game on wb window ? I hope also future Amigas
  87. will provide 320 pix fullscreen. that's what games just need.
  88.  
  89. |> 
  90. |> >you can keep game programmers from doing this in providing a powerful
  91. |> >interface that doesn't suck
  92. |> 
  93. |> again just insults.
  94.  
  95. what ? I say a game programer is more likely to use OS if it's excelent
  96. in speed end got a useful interface. I'd say this is true and I don't
  97. know what "insult" got to do with this.
  98.  
  99. |> 
  100. |> >and so won't force them to do direct poking
  101. |> >something.
  102. |> 
  103. |> Nobody is forced.
  104.  
  105. Also nobody is forced to use the OS. 
  106.  
  107. :) as long as you are not dictator :) Seen lotsa cars with "M-VE" signs
  108. last time :) shudder :)
  109.  
  110. |> 
  111. |> -- 
  112. |>                                 Michael van Elst
  113. |> 
  114. |> Internet: mlelstv@serpens.rhein.de
  115. |>                                 "A potential Snark may lurk in every tree."
  116.  
  117. -------------------------------------------------------------------
  118. fischerj@Informatik.TU-Muenchen.DE (Juergen "Rally" Fischer)   =:)
  119.